• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. John Sartoris
    3. Posts
    J
    • Profile
    • Following 0
    • Followers 0
    • Topics 7
    • Posts 50
    • Best 5
    • Controversial 0
    • Groups 0

    Posts made by John Sartoris

    • RE: Help with Win10 sysprep

      @MRCUR said:

      @Arrowhead-IT Edge is also removed. We’re deploying Enterprise with all of the “Modern” apps removed at first. We’ll add some back later, but for now we’re starting with a minimal install.

      Pretty much in the same boat here. We don’t like taking away features, but don’t have plans for them yet. We only have a hand full of windows touch devices, but we are talking about a student cart of Surface tablets for an art class. Need to find out about deployment tools for modern apps. Is it part of the Meraki free MDM?

      posted in Windows Problems
      J
      John Sartoris
    • RE: Help with Win10 sysprep

      @MRCUR said:

      @John-Sartoris I’m not sure what the issue is with connecting to the network. Below are the commands to remove the “Modern” apps and make it so they never reinstall.

      Get-AppXPackage -AllUsers | Remove-AppXPackage
      Get-AppXProvisionedPackage -Online | Remove-AppXProvisionedPackage -Online

      I tried that when I started, unfortunately it didn’t seem to do anything for me. Then I found the “All Users” apps that also needed to be processed, and the “All Users” versions of the Remove commands don’t pipe. So you have to run each app manually, that where the script I linked to comes in.

      @Arrowhead-IT said:

      devcon -r remove *

      I have been using a custom script for a few years with Win7 that processes device drivers using this set of commands and a network driver store. Works great, I’ve got one image that works on at least a dozen different models of machine. As long as it’s AHCI and I’ve included the network drivers in the image all it good and it will send me an email when it’s done with the cleanup.

      Now to sort out if FOG can tell the difference between a workgroup and a domain. I know the answer in the past was no.

      posted in Windows Problems
      J
      John Sartoris
    • RE: Help with Win10 sysprep

      While trying to answer @Wayne-Workman 's questions, I started to isolate my problem piece by piece. I installed an absolute fresh copy on Win10 ENT 1511 and ran my cleanup and sysprep. It broke in the same way. I repeated with just sysprep and it got past my problem, so it wasn’t sysprep, it was my cleanup…

      I think I have it sorted. I know for sure I had 2 things happening. First was removing the background updated store apps. I reverted to my backup and followed the workaround I found…

      Really MS??? don’t connect the computer to the network??? How is that possible with installing 60+ software packages and countless windows updates?

      So rather than uninstalling the updates, the workaround is to login with a different user and delete the “setup” user profile, then run sysprep from the secondary account. I used a domain account for installing software from our network resource, and then used our backup local user for the clean and sysprep. This got me past the OP problem. I guess it was related to the store apps I removed. I was using this script to process them in bulk. But now I’m not doing that at all.

      My second problem that showed up after this was fixed was with the <ComputerName> option. I tried it several ways and all I was getting was “could not parse or process” “[specialize]”. In the end I simply removed the line, and now it assigns a random name and completes, FOG will take care of the rest.

      One other thing I found that I’m not sure about was adding the product key. I am using KMS and I thought I updated it from my Win7 file, but when I double checked it was missing.

      posted in Windows Problems
      J
      John Sartoris
    • RE: Help with Win10 sysprep

      I’ve been trying to find someone saying that, and I couldn’t find it. In the past I remember reading that it wasn’t even needed for 7, but I can’t find that anymore.

      As for any reason I know it might be needed, is just regenerating some of the unique install IDs. The machine ID and a few other locations are used for tracking in WSUS and Windows KMS Server. I have however seen that these were not even being regenerated by my last few rounds of Win7 syspreps. Sure I have “skip rearm” set. I don’t remember why but I do remember it being needed/suggested somewhere.

      I’ve had to manually rearm and regenerate quite a few hosts this last year in efforts to keep my kms server active. Fortunately it’s as simple as 2 bat files and I only need to get 30ish to have a safety margin beyond the 25 threshold.

      If I could run these automatically on deploy, or maybe better would be to alter my pre-sysprep cleanup to run it and as you suggest skip sysprep.

      I’ll run some tests. Still curious what went wrong and why “CloudExperienceHostBroker” is causing trouble.

      posted in Windows Problems
      J
      John Sartoris
    • Help with Win10 sysprep

      I thought I was going to be in the clear, I made my way past all of the Generalize issues, removal of the MS Store app that I didn’t install, etc. Updated my unattend.xml and ran my scripted cleanup and sysprep. The script isn’t anything fancy, just a process to empty temp files and such.

      Problem is after I capture and deploy the image, the target gets stuck at “Just a moment” and reboots. This isn’t a problem with imaging either, the source system does it also. I’ve pulled the event log from the machines and found what I’m pretty sure is the issues, I just have no idea what I can do about it.

      The process C:\Windows\System32\CloudExperienceHostBroker.exe (l-2640-win10i) has initiated the restart of computer l-2640-win10i on behalf of user NT AUTHORITY\SYSTEM for the following reason: Operating System: Reconfiguration (Unplanned)
       Reason Code: 0x20004
       Shutdown Type: restart
      

      This happens over and over again. I found one suggestion in all of my searching, to enable UAC via registry modification. Well, my was already enabled and disabling it didn’t help.

      posted in Windows Problems
      J
      John Sartoris
    • RE: NFS problems after upgrade to trunk

      @george1421 @Wayne-Workman

      Both nodes are back online now. I had a left over “-T” in /etc/default/nfs-kernel-server on the storage node from my attempts to disable NFSv4. What I was reading said NFSv3 doesn’t use TCP and is only UDP. Well, however fog connects it needs TCP with v3.

      Here is where I ended, I don’t know if the RPCNFSCOUNT of 48 is needed to be increased from the default 8, but I read that this increases the threads for nfs workers.

      /etc/default/nfs-kernel-server

      # Number of servers to start up
      # To disable nfsv4 on the server, specify '--no-nfs-version 4' here
      RPCNFSDCOUNT='48 --no-nfs-version 4'
      
      # Runtime priority of server (see nice(1))
      RPCNFSDPRIORITY=0
      
      # Options for rpc.mountd.
      # If you have a port-based firewall, you might want to set up
      # a fixed port here using the --port option. For more information,
      # see rpc.mountd(8) or http://wiki.debian.org/SecuringNFS
      # To disable NFSv4 on the server, specify '--no-nfs-version 4' here
      RPCMOUNTDOPTS='--manage-gids --no-nfs-version 4'
      
      # Do you want to start the svcgssd daemon? It is only required for Kerberos
      # exports. Valid alternatives are "yes" and "no"; the default is "no".
      NEED_SVCGSSD="no"
      
      # Options for rpc.svcgssd.
      RPCSVCGSSDOPTS=""
      
      # Options for rpc.nfsd.
      RPCNFSDOPTS=""
      

      /etc/idmapd.conf

      [General]
      
      Verbosity = 0
      Pipefs-Directory = /run/rpc_pipefs
      # set your own domain here, if id differs from FQDN minus hostname
       Domain = localdomain
      
      [Mapping]
      
      Nobody-User = nobody
      Nobody-Group = nogroup
      
      [Translation]
      Method = nsswitch
      

      /etc/default/nfs-common

      # If you do not set values for the NEED_ options, they will be attempted
      # autodetected; this should be sufficient for most people. Valid alternatives
      # for the NEED_ options are "yes" and "no".
      
      # Do you want to start the statd daemon? It is not needed for NFSv4.
      NEED_STATD=
      
      # Options for rpc.statd.
      #   Should rpc.statd listen on a specific port? This is especially useful
      #   when you have a port-based firewall. To use a fixed port, set this
      #   this variable to a statd argument like: "--port 4000 --outgoing-port 4001".
      #   For more information, see rpc.statd(8) or http://wiki.debian.org/SecuringNFS
      STATDOPTS=
      
      # Do you want to start the gssd daemon? It is required for Kerberos mounts.
      NEED_GSSD=
      
      posted in FOG Problems
      J
      John Sartoris
    • RE: NFS problems after upgrade to trunk

      @Wayne-Workman said:

      @John-Sartoris said:

      Edit - Correction, the master node is working, but the storage node still doesn’t mount…

      Am I mistaken, or was the problem exactly the opposite before?

      You are half right :), the nodes have swapped, but before was a “connection refused”, not it’s “operation not supported”

      posted in FOG Problems
      J
      John Sartoris
    • RE: NFS problems after upgrade to trunk

      @george1421 @Wayne-Workman

      Well, it’s working. I’m not entirely sure what happened, but I can tell you what I noticed that made me try the full deploy again was the “fog.mount” command in debug mode. I was looking at all the commands available looking for ideas to try and I saw that. I tried it and it completed back to a prompt, then “mount” listed /images as connected. I still was unable to mount manually but…

      One thing I did do was reset the fog user password on the master server. I tried to download a kernel ( i’m not even using it) and received a complaint that the ftp password was wrong and it should be a long crypted string. Then when trying to create a deploy task the ftp password was again wrong, and it should be the normal short password I started with. I haven’t tried to download another kernel to test for the error.

      Edit - Correction, the master node is working, but the storage node still doesn’t mount…

      From debug mode mount is returning “operation not supported” to storage node:/Images

      posted in FOG Problems
      J
      John Sartoris
    • RE: NFS problems after upgrade to trunk

      @george1421 @Wayne-Workman

      I understand what you are telling me about rebuilding. Any reason I should switch from Ubuntu to CentOS like you suggest? Ever since I switched from Gentoo, probably 10 years ago, I’ve been using Ubuntu. It’s what I know, I could probably pick up the the intricacies of CentOS vs Ubuntu easily enough, but if there is no reason then why?

      As for my current state, the storage node stopped working, and I haven’t been able to get it back. I’ve upgraded both to Ubuntu 14.04, and after a Grub related issues on the master node both are back to the same state for NFS. I have however verified that I have NFSv4 disable and am working only in v3. I found the log file showing connections to rpc.mountd.

      /var/log/syslog shows a successful connection being made.

      Feb  9 13:30:42 lk-fog-01 rpc.mountd[1360]: authenticated mount request from 10.2.ccc.bbb:911 for /images (/images)
      

      reports just the same as the storage node which completes and can browse without issue.

      Feb  9 13:35:27 lk-fog-01 rpc.mountd[1360]: authenticated unmount request from 10.1.yyy.xxx:895 for /images (/images)
      
      posted in FOG Problems
      J
      John Sartoris
    • RE: NFS problems after upgrade to trunk

      @george1421

      I’ve tried to disable NFSv4 as per http://andy.delcambre.com/2007/06/25/disabling-nfsv4-on-ubuntu.html and the comments in “/etc/default/nfs-kernel-server” however the problem still exists.

      @Wayne-Workman

      Just wanted to say I really appreciate all the help you have both been.

      I’m out for the day. I’ll pick this up again in the morning.

      posted in FOG Problems
      J
      John Sartoris
    • RE: NFS problems after upgrade to trunk

      @george1421

      As posted earlier, config matches on both servers.

      /etc/exports

      /images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
      /images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)
      

      nfs-kernel-server 1.2.5-3ubuntu3.2 does appear to be NFSv4, however this is the version running on both servers. It may have been original with the working storage node, while the master may have been upgraded to 3 to 4.

      http://packages.ubuntu.com/precise-updates/nfs-kernel-server

      also NFS does appear to be reaching the server from the client.

      # netstat -t -u -c | grep 10.2.ccc.bbb
      tcp        0      0 fog-01:ssh  10.2.ccc.bbb:41650       ESTABLISHED
      tcp        0      0 fog-01:nfs  10.2.ccc.bbb:692         ESTABLISHED
      
      
      posted in FOG Problems
      J
      John Sartoris
    • RE: NFS problems after upgrade to trunk

      @Wayne-Workman

      Do NFS connections get logged on the server? I’ve tried several suggestions I’ve found but I don’t see any messages for successful or failed connections. I’m sure I’ve seen connection attempts in a log before when testing VMWare ESXi at home, just can’t recall where.

      Looks like the export option “no_acl” deals with the file system ACLs not anything network related. And the export is to * so in theory anyone should be able to connect.

      posted in FOG Problems
      J
      John Sartoris
    • RE: NFS problems after upgrade to trunk

      @george1421

      I’m trying to manually mount from the FOG Client now, and I’m receiving a connection refused.

      @Wayne-Workman
      Configuring another VM would be possible, but quite a heavy bit of work for what sure seems to be a firewall config or NFS ACL issue that happen during OS or Fog upgrade.

      posted in FOG Problems
      J
      John Sartoris
    • RE: NFS problems after upgrade to trunk

      @Wayne-Workman

      I understand and agree with the assessment, but nothing has changed on the LAN in weeks other that the fog server updates. Firewalls are disabled and allowed for good measure. I even just tried added iptables rules without success.

      posted in FOG Problems
      J
      John Sartoris
    • RE: NFS problems after upgrade to trunk

      @Wayne-Workman said:

      @John-Sartoris refused is different than denied… Have you checked for IP conflicts?

      I haven’t specifically checked, but this server is configured in the same way as the rest in our environment. DHCP with a reservation. This is the only server that should get this address. Access ports are not configured in this vlan. I have not had any issues connecting to the server expect via NFS. Ping and SSH work from debug client.

      posted in FOG Problems
      J
      John Sartoris
    • RE: NFS problems after upgrade to trunk

      @george1421 said:

      I didn’t read all of the posts here, but could you do a showmount -e 127.0.0.1 This will show us what you have NFS shared on your FOG server.

      That’s shows that the exports are proper and they do actually work from the storage node cross site, but a client on the local site can’t connect.

      posted in FOG Problems
      J
      John Sartoris
    • RE: NFS problems after upgrade to trunk

      @Wayne-Workman

      From the client in debug…

      mount: mounting 10.2.yyy.xxx:/images on images failed: Connection refused
      

      sounds to me like it’s still a permissions or acl type issue.

      posted in FOG Problems
      J
      John Sartoris
    • RE: NFS problems after upgrade to trunk

      @Wayne-Workman said:

      @John-Sartoris Are you using the location plugin?

      Yes, I am using the location plugin. Is there a known issue?

      I completely understand. When it doesn’t make sense double check things the wouldn’t make sense…

      IP addresses and Paths are correct. Re-saved, I also double checked and re-saved the node choice in the location plugin.

      Still no luck. Is there anyway I can get more detail on the client machine to see exactly what is erroring? It just says “An error has been detected!”, it doesn’t specify.

      posted in FOG Problems
      J
      John Sartoris
    • RE: NFS problems after upgrade to trunk

      @Sebastian-Roth

      Same places as the working node.

      /images:
      total 72
      drwxrwxrwx 18 root root 4096 Feb  4 12:22 .
      drwxr-xr-x 26 root root 4096 Feb  8 09:01 ..
      -rwxrwxrwx  1 root root    0 Jul 29  2014 .mntcheck
      
      /images/dev:
      total 8
      drwxrwxrwx  2 root root 4096 Jul 29  2014 .
      drwxrwxrwx 18 root root 4096 Feb  4 12:22 ..
      -rwxrwxrwx  1 root root    0 Jul 29  2014 .mntcheck
      
      posted in FOG Problems
      J
      John Sartoris
    • RE: NFS problems after upgrade to trunk

      @Wayne-Workman

      I was already at 777 on the master but after resetting own:group and perms for good measure, and restarting nfs-kernel-server, still no luck on the deploy.

      posted in FOG Problems
      J
      John Sartoris
    • 1 / 1